Importance of Getting Entire Team Involved in Estimation

I’ve never been a huge fan of horror movies. But I have always liked Halloween, especially as a kid. I loved dressing in a scary costume and trying to frighten my friends or other trick-or-treaters. And I admit to getting a bit of a thrill from walking through a well executed haunted house.

But, there are aspects to every agile transformation that can send a shiver down a spine--and those moments are not quite so thrilling. So let’s take the fear factor away from five things that might make you want to run for cover along your agile journey--first by naming them and then by talking about why they aren’t so scary once you understand how they work.

Eeek! Agile Has No Design Phase!

Architects and senior tech people are often frightened by the idea that there’s no design phase in agile. While it’s true that agile teams shun an upfront design phase, that does not mean that design doesn’t occur.

Design on an agile project is characterized by two attributes: it is both emergent  and intentional. An emergent design is one that comes into existence over time. Rather than being done all upfront in a single phase, design is an ongoing activity. The design emerges through the creation of the software.

But design is also intentional. This means the design does not emerge randomly. Design is guided by the intent of the senior technical people on a project or perhaps even someone in a designated architect role.

If the senior technical people are concerned about a particular part of the system, the product owner should prioritize a product backlog item or two in that area. This will allow the team to explore that part of the system by building some small part of that system. Doing so will help identify the appropriate design in that area.

Allowing design to emerge guided by the intent of the team will reduce the terror of there being no design phase in agile.

Help! I'll Become a Generalist.

A common myth that has persisted since the earliest days of agile is that agile teams don’t value specialists and want everyone to become a generalist. This is frightening to many people for two reasons: First, no one enjoys all types of work equally and second because of the concern it could impact future employability if someone can do four things adequately instead of one thing extremely well.

The idea that everyone becomes a generalist on an agile team is completely false. If I’m coaching a team that has the world’s greatest JavaScript wizard, I’m going to want that superstar doing amazing things in JavaScript, not learning how to become a DBA.

Yes, agile teams value members who have multiple skills--the tester who can also write some JavaScript, for example. One of the easiest ways to balance the amount of work between two skills is to have someone who can do either type of work. If, for example, your team finds it hard to balance the amount of work in an iteration between programmers and testers, having someone who is adept at both coding and testing can solve that problem.

A goal in agile is the formation of cross-functional teams, which means the team has all skills needed to produce a finished, working deliverable within the iteration. Doing that does not require each person to have all the skills of a cross functional team.

If the thought of becoming a generalist makes your hair curl, understanding that a cross-functional team still allows for specialists should put your mind at ease.

Oh No! We Can’t Plan or Predict Dates!

Management is often chilled to the bone by the idea that an agile team can’t plan or predict dates further ahead than the current iteration or sprint.

Fortunately, this does not need to be the case.

Yes, agile teams give up the false comfort of overly planned projects with intricately drawn Gantt charts showing a precise completion date way in the distant future. But that does not mean agile teams are unable to make plans or predict future delivery dates or scope.

A huge benefit of agile is that every iteration the team turns the crank on the entire development process. That is, they take an idea usually expressed as nothing more than a simple user story, and they full implement that feature. This means that every few weeks, a team can measure its progress: They can know how much they got done.

Contrast this with a traditional development projects, perhaps one with an analysis phase, a design phase, a coding phase and, finally, a testing phase. When that team measures its progress over a period of time, they are measuring only how fast they are at doing one (or perhaps two) types of work. How fast a team is at doing design says nothing of how fast the team will be at coding and testing.

The key with agile planning is embracing the uncertainty--admitting that it’s impossible to know all the functionality that will be built before starting the project--and then adjusting for that in a variety of possible ways. When teams combine this realization with the ability to actually measure the amount of work done every iteration, it leads to reliable planning, which should calm the nerves of a management team daunted by the prospect of having no predictability.

Yikes! I Won't Have a Job!

The prospect of transitioning a team or company to agile is enough to scare the pants off some managers who are concerned they won’t have a job after the transition is complete.

This is understandable. It would be dismaying to start a transition effort aimed at helping a company knowing that it may make your role superfluous.

However, I can clearly say that I have never helped a company adopt agile and then seen that company say, “OK, we no longer need people with job title such-and-such. They’re all terminated.” It just doesn’t happen. Sure, a company may decide a specific job title is no longer needed or appropriate. But the individuals with those titles still have jobs. And in most cases, I believe they end up with better, more focused jobs. With that being said, it is true that some people will end up with less direct control over people or decisions and they may find that frustrating, even to the point of leaving the company.

But because I have never seen significant layoffs of any role or skill as part of transitioning to agile, I believe this fear is as misplaced as that of a zombie apocalypse.

Zoinks! Scrum Has Too Many Meetings!

Like many people, I really hate meetings. In fact, it’s largely why I do what I do. Most days I have no meetings at all. Pure bliss.

But even I can acknowledge that some meetings are important and useful. And that includes the four standard meetings of Scrum: the sprint planning meeting, the daily scrum, the review, and the retrospective.

The thought of all these meetings, however, can send some people into a cold sweat.

Here’s the problem with Scrum meetings--they have names. When something has a name, it’s easier to attack. In my experience, many teams who adopt Scrum had more meetings before Scrum. But the meetings didn’t have names and were mostly ad hoc meetings called to resolve specific issues.

Here’s an experiment I like and that you can easily do to see if you’re having significantly more meetings with Scrum. Randomly pick a month on your calendar from before you started adopting an agile approach. Open that month up in your calendar software and add up the time spent in meetings. Then add up the average time in your Scrum meetings and see how they compare.

Based on my experience, you might well be surprised by the results. But because those pre-agile meetings were not recurring, regular meetings, they didn’t have names and so they don’t stick out in our memories the same way a named meeting, like “Sprint Planning,” does.

The key for overcoming the terrorizing thought of too much time spent in meetings is keeping the meeting short. Occasionally I’ll work with a team that I need to encourage to spend more time in a certain meeting. But most teams spend too much time in each of the standard meetings. Once they find ways to shorten them, those meetings should no longer frighten us out of our wits.

Relax...those Ghosts and Ghouls Aren’t Real.

While it can be fun to walk through a haunted house or dress in a scary costume, most of us can easily remember that it’s all make-believe. Those ghosts, ghouls, vampires, werewolves, and crazed lunatics with chainsaws aren’t real.

And neither are the five agile legends I’ve outlined here. And while no one can be faulted for being afraid at first, education and experience will pull the mask off the myths, leaving us reassured rather than unnerved.

What Have You Been Afraid Of?

What part of transitioning to agile did you find the most scary? How did you overcome your fear? Please share your thoughts in the comments section below.

A common problem with user stories is how to add the right amount of detail to a story so that it is ready to be brought into an iteration or sprint.

It's an important balancing act. Bring a story into an iteration before it is sufficiently understood and there will be too many open issues for the team to complete it within the iteration. But try to resolve every open issue and add every little detail to a story and you end up with functionality that takes far too long to make it into the hands of users.

Like Goldilocks and the bears, we don't want stories with too little or too much detail. We want detail that is just right.

And we want that detail at just the right time, too. When  detail is added to a user story is every bit as important as how much  is added.. If details are added needlessly far ahead of when the story is worked on, there is a strong chance that some of those details will be wrong.

Trying to resolve all open issues in advance is costly. It can lead to rework if wrong answers are provided. It can lead to longer time-to-market as team members are stalled waiting for answers. It can also lead to a loss of creativity as programmers are merely told exactly how to implement something.

Not Everything Needs to Be Known Before Starting

When thinking about working on a user story, it is useful to realize that the team doesn't need to know everything before it starts a story.. All open questions need to be answered before a story is finished , but not all need to be answered before the story is started.

As an example, suppose a team is working on a story such as, “As a user, I am locked out after n failed attempts to log in.” The team clearly needs to know the number of failed attempts before they call this story done. But both programming and testing can begin without that answer.

What You Can Do Right Now

If you or your team has ever struggled to include the right amount of detail at the right time, I’ve created a free 13-minute training video to help.

In it, you get concrete advice on how you can know the right amount of detail to add to each user story. I’ll also share with you the one question I ask in every retrospective to make sure detail is being added at the right time and in the right amount.

Watch now and see how to add the right amount of detail at the right time.

This is the third in a series of videos I’ve created to help you write better user stories. But it will only be available through 11 October. So if you’re like the majority of agile teams who struggle with adding the right amount of detail, go watch the video right now. I know you’ll find it helpful.

What’s Your Experience?

Does your team sometimes struggle to add the right amount of details at the right time to user stories? How do you ensure stories are neither too vague nor too detailed? After you watch the video lesson, please share your thoughts in the comments section below.

Isn’t it extraordinary that something as fundamental as emotion is only just finding its place in our world? Recent advances in understanding how human brains work have given us a new focus on emotion, showing us how it directs and influences us.

Skills to Build Relationships

“The trouble is that education is so academic,” Catherine begins, “It’s based on knowledge and not the ability to build relationships.”  Aga too had highlighted that the skills needed in today’s AI driven world are those that differentiate us from robots. Knowledge can be accessed online or programmed in but thriving in a world that’s in a constant state of fast change needs the ability to collaborate and communicate effectively.

Research indicates that emotional intelligence is twice as important as IQ when it comes to getting where we want to go in life, and yet emotion is still largely ignored by our education system. “The gap is that we don’t learn about emotions at school,” Catherine continues, “Actually, teacher training generally doesn’t cover emotions at all. It’s a real omission. Emotions are the route to self awareness and self knowledge, and these things are critical for success.

 “In schools emotions tend to be branded as a bit of an inconvenience. Children are encouraged to control their emotions, but they are not empowered to understand and respond to them. Think about it, a teacher may well implore a child not to cry, or they may say that a child shouldn’t be angry and apply correctives to prevent it. We are not taught to give space to emotion.”

Emotions as Warning Lights

Catherine uses an analogy of a car to illustrate how she sees the role of emotions. “If your car flashes a red warning light that the oil is low, you may find that very irritating. It doesn’t make you unplug the light to stop the flashing. You consider what is causing the alarm and most likely you then attend to the car’s needs, giving it what it is missing to restore the balance to its operations.

“This is the role of emotions in communication. They are our warning light system, and we ignore them at our peril.

“We are told that good communication comes from gaining congruence between what we think and what we say. Congruence is also needed with what we feel. We cannot ignore that bit.”

Telling a child “There is nothing to be scared of” teaches them to mistrust their own emotions. Generation Agile points to the need to build children’s confidence so that they trust their instincts and feel empowered to share ideas and innovate. Just consider how the common retort “Never answer back” may sow seeds that prevent the transparent sharing of ideas and collaboration in the workplace.

“Ultimately,” Catherine concludes, “We need to educate children for a world that we won’t live in. Change is so fast that we can’t yet imagine the challenges that they will face and the context that they will live in. Today’s children will be tomorrow’s workers, and need the skills now to be confident communicators, to be able to collaborate and explore new things without fear.”

Humans are social animals. The way we communicate, collaborate, and explore and innovate has defined our evolution so far. It will define our future too. No surprise then that Communication is one of the 3Cs of Agile Leadership and a core principle of Agile Project Management.

I’ve been working with a company to revamp their bonus and incentive structure as part of the organization’s desire to become agile. No matter how well designed and executed an agile transition is, if incentives remain in place that encourage non-agile behavior, that’s how people will behave.

In “Succeeding with Agile,” I referred to this as organizational gravity. Unless enough of an organization’s culture is changed in becoming agile, organizational gravity pulls the organization right back to where it started.

Improperly aligned bonuses and incentives are some of the biggest sources of organizational gravity.

Incentives and Bonuses Are Different

Before looking at how we can create proper bonuses and incentives, let me clarify the difference between a bonus  and an incentive.

An incentive is a reward given to an individual or team for achieving a stated goal. An incentive is offered in advance and is meant to motivate behavior in predictable ways. When my youngest daughter was little, I told her that if she cleaned her room by 3:00 p.m., I would take her to see a movie. That was an incentive.

In contrast, a bonus is not stated in advance. Rather it is announced and given at the time something is accomplished. Again using my youngest daughter as an example, when she came home from school with a great grade on a test I knew she’d studied hard for, I told her we’d celebrate that accomplishment by getting ice cream. That was a bonus.

Incentives and bonuses are both rewards  with the key difference being that an incentive is announced in advance whereas a bonus is announced on the spot.

Some Troublesome Rewards

Bonuses and incentives can work against the goals of agile. For example, rewards that single out individual performers discourage teamwork. I’ve seen these in the form of “Programmer of the Year,” “Team Member of the Month,” “Most Valuable Contributor” and more.

Other types of rewards encourage suboptimizing behavior. Many of us have stories about testers who were rewarded based on the number of bugs they found. This type of reward led one tester I met to log over 200 entries into the defect tracking system for a single bug.

The bug was simply that a value was being improperly calculated and displayed on the screen. But the product ran on four operating systems (the current and prior versions of WIndows and Mac OS X), eight different browsers (the current and prior versions of four browsers), and was supported in seven different languages. So one bug was reported on Firefox v59 on Windows 8.1 in French. The same bug was reported on Safari 6.2 on MacOS 10.8 in English, and so on.

Bug reports like this wasted everyone’s time. But that tester sure looked productive in the “Bug Finder of the Month” contest.

How About Money?

Financial rewards are almost always a bad idea. Financial rewards are often introduced by a well-meaning boss who wants a team to make a particularly aggressive deadline. The boss will offer an enticing amount to the team if they can deliver by then.

So far, so good. But the problems arise on the next project. On that, the team may start on schedule, but they’ve been trained that if they get a little behind (or perhaps even only if they report themselves as a little behind), the boss will offer a bonus. This becomes a dangerous cycle.

Besides, financial rewards don’t tap into people’s intrinsic motivations. There’s absolutely nothing wrong with money. Most of us wouldn’t show up for work without at least some paycheck. But we’d like to tap into deeper motivations than the purely financial.

The Team That Taught Me About Financial Rewards

I learned a lot from a team many years ago to whom I gave a large financial bonus. This was two teams of 12 developers, and I gave them a bonus of $75,000, which would be more than $6,000 per person … if I split the bonus evenly.

And that was the trouble. I had allocated the bonus in the budget, so I had the money as a pool to give them. But when it came time to decide how I would give it to the team, I couldn’t decide.

Should I:

• Give the same amount to each person? If I gave each person $6,000, that seemed unfair to those with high salaries and overly generous to others.
• Give an amount proportionate to each person’s salary? This seemed the opposite.
• Weigh the amounts by how many months the person had been on the project? It seemed unfair to give the same amount of money to a developer who joined the project a month ago as someone who had worked six months on it.
• Give to the developers who had worked on this project but had been transferred off? It seemed unfair to leave them out, but if they weren’t there during the hardest period, did they deserve as much?

I couldn’t decide. I went back and forth on this. Some of the key people on the project knew I was planning this bonus and wrestling with this decision. They offered advice. But each person’s suggestions were always very aligned with what would reward them the most.

And so, I gave up.

I told the team I would give them $75,000 but it was their decision how to allocate the bonus.

I told them the issues I’d been struggling with and said that whatever they decided would be fine. But they had to all agree on the process they’d use and the allocation.

A week after I shifted the problem to them, we had a team meeting. They told me they could not find a way to distribute the bonus money. They argued about it. And they felt the money was interfering with the strong bonds they’d built as a team.

And they gave the money back. They decided they didn’t want it.

I don’t think I’d ever been more proud of--or surprised by a team.

We ultimately decided to spend some of the money on a nice out-of-town trip for everyone plus a significant other. The rest was returned to the budget.

And it was the last financial reward I’ve offered a team.

So How Should We Reward an Agile Team?

So how should we reward an agile team? I think the most important consideration is that rewards should encourage teamwork rather than individual performance. I favor rewards (both incentives and bonuses) that are given to everyone on the team.

This doesn’t mean there’s no role for individual rewards. I think those can be fine, but for individual rewards, I prefer to make them smaller, at least in relation to team rewards.

For example, I’ve worked with a few product owners who carry five-dollar bills and give them to team members who could quote the project’s elevator statement or three main goals when asked. No team member’s life was improved by $5. It was more the knowledge that they passed the test when asked. More than one of these team members pinned the $5 to their cubicle wall.

Similarly, a handwritten note can do wonders in this era of constant email deluge. Take the time to write a note every now and then thanking a team member for something special and specific they did.

One of my favorite rewards for a team is time. TIme is something that everyone seems constantly short of. I’ve rewarded a team with time a couple of different ways, which have been consistently well received. For example, you can offer a team an incentive of a week off if they meet some delivery milestone.

Or if a full week off is too much, offer the team a week (or a sprint) where all work is of their own choosing. They can refactor old code the product owner has been resistant to approving if they choose. They can experiment with new technologies. They can catch up on reading if they want. Whatever they choose is fine.

Another option is to give the team knowledge. If they achieve some goal, send everyone to a conference. If appropriate, everyone goes to the same conference. That’s especially good as you can include some fun time before or after. Or, if it’s better, allow each person to pick their own conference to attend some time during the year.